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Preface 



New applications and improved design methodologies or tools for elec- 
tronic system design often require the application of new design lan- 
guages. Vice versa, the availability of appropriate design languages en- 
ables new design methodologies, and allows designers to deal with new 
kinds of applications — often sticking on an established design language 
is a ‘show stopper’ for the application of new design methodologies. 

An example for the impact of design languages on methodologies or 
tools from the past is the upcorne of register transfer synthesis which 
was enabled by HDLs such as Conlan, and later VHDL or Verilog which 
allowed designers to specify the behavior of designs at register transfer 
level. Vice versa, these languages would not have become so popular 
without the availability of tools for register transfer synthesis. A recent 
example for the interaction of design languages and applications is the 
upcorne of SystemC. The specification of complex HW/SW systems in 
HDLs, even if extended and with C interfaces, is not an appropriate so- 
lution for software developers. SystemC is one solution for this problem, 
and can enable new tools for architecture exploration and synthesis at 
higher level of abstraction. 

In the future, ambient intelligence, automotive systems, etc. will com- 
bine IP cores and complex software systems with analog components 
such as RF or power electronics, and might have to be co-simulated 
with a physical environment. Established hardware description lan- 
guages seem to be not appropriate for the design of such systems as 
long as they provide no answers to questions such as: How can we hide 
the growing complexity behind more abstract models? Are there ap- 
proaches to hide the heterogeneity behind common models? How can 
we handle the verification of such systems? 

This book includes selected contributions on languages for the specifi- 
cation, design, and verification of electronic and heterogeneous systems. 
These contributions give an overview of recent research topics that try to 
answer the above questions. The book is structured in five parts with 22 
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contributions and comments from Piet van der Putten, Eugenio Villar, 
Alain Vachoux, and Wolfgang Muller: 

■ The first part includes approaches to use UML and object oriented 
methods for the specification and design of embedded HW/SW 
systems. 

■ “C-Based system design” describes new means for and experiences 
in modeling HW /SW systems with C-based languages such as Sys- 
ternC. 

■ “Analog and Mixed-Signal Systems” presents recent research ac- 
tivities and practical experiences in the design of heterogeneous 
systems. 

■ “Languages for Formal Methods” aims at modeling techniques that 
enable new techniques for verification. 

■ “Applications and new languages” describes requirements for de- 
sign languages from automotive software engineering, and gives an 
overview of SystemVerilog as a new hardware description language. 

All contributions were selected from the best papers presented at the 
“Forum on Specification and Design Languages 2003”. As organizers of 
this conference we would like to thank all people who supported this 
important event: The members of the program committee of FDL 2003, 
and the PC chairs Wolfgang Muller (LFM), Piet van der Putten (UML), 
Alain Vachoux (AMS), and Eugenio Villar (CSD) who reviewed nearly 
100 submissions, and who selected the best of them. We would also like 
to thank Wilhelm Heupke who successfully managed the local organiza- 
tion together with us, and Max Slowjagin for managing correspondence 
with authors, and layout. Last, but not least we would like to thank 
Jean Mermet, Florence Pourchelle, and the ECSI staff for taking each 
year again the challenge to organize a new “Forum on Specification and 
Design Languages”. 



Christoph Grimm, Klaus Waldschmidt 
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UML-BASED 

SYSTEM SPECIFICATION & DESIGN 




Emerging highly programmable platforms enable the realization of 
very complex systems. The importance of the Unified Modelling Lan- 
guage (UML) in embedded system design is therefore growing fast. The 
UML workshop of FDL aims at UML-based design methods from speci- 
fication to (automatic) synthesis. Such methods start from target/plat- 
form independent modelling and enable mapping on platform specific 
elements. From four UML sessions we selected five papers that are rep- 
resentative for current research activities in the field. 

From the session on “Model Driven Architecture” we selected a paper 
by Donrinik Frohlich, Bernd Steinbach and Thomas Beierlein, called 
“UML-Based co-design for run-time reconfigurable architectures”. It 
presents a development environment based on an MDA approach, that 
uses UML 2.0 for specification, modelling, documentation, and visual- 
ization throughout all phases of development. The MOCCA (MOdel 
Compiler for reConfigurable Architectures), implements the methodol- 
ogy and automatically performs system validation, platform mapping, 
and application synthesis. Very interesting is the MOCCA action lan- 
guage and the mapping processes. 

From the session on “Transformations & Code Generation” we selected 
“a unified approach to code generation from behavioral diagrams” writ- 
ten by Dag Bjorklund, Johan Lilius, Ivan Porres. The paper describes 
how to use ‘Rialto’ intermediate language to capture the semantics of 
UML behavioral diagrams, such as statechart, activity and interaction 
diagrams which is an interesting work because Rialto has a formal seman- 
tics given as structural operational rules and supports semantic varia- 
tions. It can be used to uniformly describe the behavior of a combination 
of several diagrams and as a bridge from UML models to animation and 
production code. 

From session “Real-Time and System-level modelling” we selected two 
papers. The first paper is by Jinfeng Huang, Jeroen P.M. Voeten, Andre 
Ventevogel and Leo van Bokhoven, called “Platform-independent design 
for embedded real-time systems”. It is an important contribution be- 
cause it describes essential characteristics that current tools miss. It 
proposes an approach based on both platform-independent design and 
correctness-preserving transformation. It is research in the context of the 
real-time modelling language ‘POOSL’, and the tool ‘rotalumis’ that au- 
tomatically transforms POOSL models into executable code for target 
platforms, preserving the correctness properties verified in the model. 

The second paper from session “Real-Time and System-level mod- 
elling” is from Trung Hieu Phan, Sebastien Gerard and Francois Terrier, 
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called “Real-time system modeling with accord/uml methodology”. The 
method is illustrated on an automotive case that has multitasking and 
real-time constraints. The ACCORD/UML method proposes UML ex- 
tensions for modeling real-time systems and follows the MDA paradigm. 
Behaviour can be expressed early in the model itself and then imple- 
mented automatically. 

The fifth paper from the session “UML for Hardware/Software co- 
design” by Mauro Prevostini, et al., called “UML-based specifications of 
an embedded system oriented to hw/sw partitioning” proposes an ap- 
proach to define hardware/software partitioning of an embedded system 
starting from its UML system specifications. The approach is illustrated 
with a case study, a Wireless Meter Reader (WMR) dedicated to the 
measurement of energy consumption. 



Piet van der Putten 

Technische Universiteit Eindhoven 
Department of Electrical Engineering 
p.h.a. v. d.putten@tue.nl 




Chapter 1 

UML-BASED CO-DESIGN FOR RUN-TIME 
RECONFIGURABLE ARCHITECTURES 



Bernd Steinbach 1 , Thomas Beierlein 2 , Dominik Frohlich 1,2 

1 TU Bergakademie Freiberg 
Institute of Computer Science 

o 

Hochschule Mittweida ( FH ) - University of Applied Sciences 
Department Information Technology & Electrotechnique 



Abstract In this article we present an object-oriented approach and a development 
environment for the system-level design of run-time reconfigurable com- 
puter systems. We use the Unified Modelling Language (UML) for the 
specification, modelling, documentation, and visualization throughout 
all phases of development, from specification to synthesis. The proposed 
approach is based on hardware-software co-design and Model Driven Ar- 
chitecture (MDA). This way we allow for thorough and complete system 
representations, platform-independence, comprehensible and seamless 
transition from specification to implementation, and the description of 
common development artifacts and activities. In this article we will 
focus on aspects and problems which are related to object-orientation, 
UML, and MDA. 

Keywords: Unified Modeling Language, Model Driven Architecture, Platform Map- 
ping, Synthesis 



1. Introduction 

The explosion of computational highly demanding applications drives 
the development of more powerful microprocessor architectures. How- 
ever, the performance needs of these applications is growing much faster 
than the rate of improvement in processor speed. Further the ratio of 
speedup to the number of deployed transistors is steadily decreasing. 

5 

C. Grimm (ed.), Languages for System Specification , 5-19. 

© 2004 Kluwer Academic Publishers. Printed in the Netherlands. 
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Thus new computer system designs are evolving. A promising new class 
of architectures are run-time reconfigurable computer systems (RTR). 

Run-time reconfigurable computer systems generally combine a clas- 
sical microprocessor (uP) with programmable logic resources, like field 
programmable gate arrays (FPGA). The uP executes the global control 
flow and those parts of the application that would require too much 
effort if implemented in hardware. CPU-intensive parts of the appli- 
cation or critical I/O operations are performed by the FPGAs. The 
functionality implemented by the logic resources is dynamically adapted 
to the executed algorithm. Recently speedups of two orders of mag- 
nitude compared to classical computer systems have been reported for 
reconfigurable computer systems, for instance [2]. What makes these 
systems appealing is their unique combination of cost per speedup and 
flexibility. 

However, years after its inception, reconfigurable computing still faces 
a wide gap between the capabilities offered by the implementation tech- 
nology and the availability of mature methodologies and tools for the 
development of their targeted applications. For reconfigurable comput- 
ing to move out of the laboratories into general purpose computing, 
time and cost for the application design, implementation and deploy- 
ment must become comparable to software development. The suitability 
of the employed development methodology and the capability to exploit 
the flexibility of the hardware will have more impact on RTR systems, 
than the optimality of the implementation, in terms of the reached cost 
or speedup. 

We developed a methodology and a supporting tool for the object- 
oriented system-level specification, design, and implementation of ap- 
plications for RTR architectures. In our approach the system being 
developed and the target platform are specified with models. The mod- 
els are described with the Unified Modelling Language (UML), version 
2.0, and a dedicated action language [7]. Our methodology defines the 
development steps to transform the system specification into a ready- 
to-run application. A UML model compiler, MOCCA (MOdel Compiler 
for reConfigurable Architectures), implements our methodology in that 
it automatically performs system validation, platform mapping, and ap- 
plication synthesis. The synthesized application exploits the potential 
performance gains offered by the reconfigurable hardware. The MOCCA 
environment was not designed for a special class of applications, how- 
ever we envisage the acceleration of computationally intensive algorithms 
from scientific computing, automation, and communication, like boolean 
problems, neural networks, track generation, and data compression. 
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The research on development methodologies for reconfigurable com- 
puter systems is still quite new. Chata and Vernuri presented the Sparcs 
design environment and a design flow [1], However, they do not address 
system-level specification, but high-level behavior specifications. Eisen- 
ring and Platzner are developing an implementation framework for RTR 
systems, which consists of a development methodology and a design rep- 
resentation [4]. The system specification is done at the task-level. The 
framework allows for partitioning, estimation, and synthesis. Vasilko et 
al. developed a modelling an implementation technique which builds 
upon the OCAPI-XL design environment [9]. The system is specified 
with processes communicating through semaphores and mailboxes. The 
processes that can be refined to lower level descriptions which are then 
realized either in hardware or software. In contrast to these approaches 
we specify systems with objects communicating through messages. 

In the rest of this article we will present our development approach. 
The approach is motivated and outlined in section 1.2. Section 1.3 in- 
troduces system modelling and the action language. In section 1.4 we 
briefly discuss platform mapping, and in 1.5 synthesis is explained. In 
the course of discussion we will briefly introduce how each activity is sup- 
ported by the MOCCA-environment. Finally, in section 1.6 the article 
is concluded. 

2. UML-Based Co-Design Approach 

2.1 Motivation 

It is common practice today to use software programming languages, 
like Java, C, or C++, or variants of programming languages to capture 
system-level specifications, e.g. SystemC and SpecC [13], [10]. Exe- 
cutable co-specifications are commonly used as basis for system valida- 
tion and synthesis. However, these languages have a strong focus on 
implementation. This renders them actually insufficient for the purpose 
of system-level specification, because 

■ the different aspects of a system, e.g. requirements, design, im- 
plementation, and deployment, are not sufficiently separated. For 
instance, the system function is captured in one of many possible 
implement at ions . 

■ some important system aspects can not be represented adequately. 
For instance, often the specification of non-functional requirements, 
design constraints, and deployment information is captured in code, 
comments, and/or compiler directives. 
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■ the specification is inherently platform and technology dependent. 
Examples are dependencies on specific hardware, operating sys- 
tems, programming language semantics, physical data organiza- 
tion, and prerequisite libraries. 

Due to these problems, there is a growing interest in using UML as 
co-design language. The use of UML has several advantages in com- 
parison to programming language based approaches: First, in UML 
based approaches systems are specified by means of models rather than 
code. This may improve design quality and tractability of complex sys- 
tems. Second, the expressive power and generality of UML allows for 
the specification of the important system aspects, like requirements, de- 
sign, and deployment, in a consistent and comprehensive manner to the 
user. Third, the extensibility of UML makes the language adoptable to 
different application domains. 

As with UML 2.0 the formerly crude capabilities for the detailed mod- 
elling of behavior improved significantly. The UML action semantics en- 
able the complete and precise behavior specification. This is a premise 
for model execution and interchange. Action languages provide a syn- 
tax for this semantic which is suitable to the targeted application do- 
mains. Currently, there is already a number of action languages tailored 
to software-only applications, but we expect that there will be special 
co-design languages in the near future. 

2.2 Activities and Artifacts 

Figure 1.1 shows the basic activities and artifacts of our development 
approach. The illustrated approach incorporates the specify-explore- 
refine paradigm of hardware-software co-design into the concept of Model 
Driven Architecture [5] , [8] , [6] . It is a particular goal of MDA to sep- 
arate the application from the platform, comprising of hardware, op- 
erating systems, compilers etc., used for its implementation. This not 
only supports the retargeting of the application but can also simplify 
the mapping of a given application to a particular platform. 

In our approach both, the system and the target platform are defined 
by means of independent models, described with UML and an action 
language. The system is specified by means of a platform independent 
model (PIM). The target platform model (TPM) defines the services 
provided by the implementation target for system execution. 

During platform mapping the platform independent model is trans- 
formed into a platform specific model (PSM). During synthesis the sys- 
tem is synthesized by transforming the PSM into a platform dependent 
application (PDA) which can be executed on the target platform. The 
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System Specification 




Figure 1.1. UML-Based Co-Design - Activities and Artifacts 



application and its models may be validated and simulated. Addition- 
ally estimation, e.g. of implementation and execution characteristics, 
and optimizations may be performed. 

The presented methodology is neither specific to run-time reconfig- 
urable architectures nor to UML. However, in the MOCCA-environment 
it was implemented specifically for RTR-architectures and UML. 

The following sections provide a more thorough discussion of the im- 
portant development activities and artifacts. For more information and 
examples we refer the reader to [12] and [11]. 

3. System Specification 

3.1 Platform Independent Model 

The system is specified in a platform independent model of its func- 
tion, structure, and behavior. The PIM comprises the following models: 

■ an use-case model, which represents the system function by means 
of the services it provides to the system context. 



■ a design model, which represents an executable and platform in- 
dependent realization of the use cases as specified by the use-case 
model. The design model may define implementation constraints 
and execution information. 
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System modelling is finished when the design model successfully exe- 
cutes all test cases defined for the realized use cases. System function 
is specified with use cases and collaborations. To specify the structure 
subsystems, classes, interfaces, and their relationships are used. Behav- 
ior specification is done with state machines, methods, and actions. The 
model of computation is objects communicating through synchronous 
method calls and asynchronous signals. Method calls, signal sends, and 
the events they evoke are polymorphic, following similar rules as speci- 
fied in [6]. For the detailed description of behavior we use the MOCCA 
action language (MAL). A thorough discussion of MAL is beyond the 
scope if this article. 

3.2 MOCCA Action Language 

The UML action semantics are a premise for building executable and 
interchangeable UML-models. An action language should allow for full 
model access, abstract from physical data organization, and not overem- 
phasize sequential execution. The adherence to these criteria is consid- 
ered a key property of system level specification languages. For an action 
language to be suitable to hardware/software co-design, it must allow 
for 



■ model execution 

■ early verification and simulation 

■ hardware-software design space exploration 

■ automatic hardware and software synthesis 

at the system-level of abstraction. For this, the language should facili- 
tate analysis and optimization of control and data flow, and estimation of 
non-functional system characteristics, like performance, implementation 
effort, and power consumption. The need for accurate estimates suggests 
to remain as close as possible to the control flow and data organization 
of the synthesized application. 

Existing action languages, like ASL, AL, and SMALL [6] are designed 
for software-only applications in business, telecommunication, and net- 
work systems. They have a high level of abstraction, in that they do not 
make any assumptions about data organization. Although this provides 
some potential for performance optimization, it complicates estimation. 

Thus we designed the MOCCA action language. This language is com- 
pliant to the UML action semantic specification. In comparison to the 
named action languages it has a medium level of abstraction in that it re- 
quires the developer to make data organization and data access explicit. 
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However, this allows us to employ standard analysis, optimization, and 
estimation techniques. Nevertheless, we consider the support of higher 
level action languages a major research issue for the future, because they 
make much of the data concurrency explicit. MAL allows for the spec- 
ification of sequential logic, arithmetical/logical/relational operations, 
instance and link manipulation, class access, and time calculation. 

To make the language easy to use and to reduce the learning effort, 
the syntax and semantics of the language orients towards the statement 
and expressions of the Java programming language. The language does 
not overlap with concepts that already exist in the UML. However, it 
supports important UML concepts not existing in Java, like associations, 
active classes, state, and time. 

4. Platform Mapping 
4.1 Activities and Artifacts 

Given a PIM or a partial version of the PSM we proceed by map- 
ping it to the target platform. Throughout this platform mapping step 
we transform the system model such that it can be implemented on 
the target platform and the resulting application optimally exploits the 
platform resources. 

As illustrated in Figure 1.2, platform mapping is performed such that 
hardware platform mapping is performed before software platform map- 
ping. 




Target Platform Model 



Target Architecture Model 



Platform 

Specific Libraries 



Figure 1.2. Platform Mapping - Activities and Artifacts 

First, throughout hardware platform mapping, basic behavior, as speci- 
fied with UML actions, is partitioned among the hardware components. 
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The result of this step is a hardware specific model of the system (HSM). 
During software platform mapping this model is transformed to a PSM, 
by mapping the behaviors which require additional run-time software 
support to the respective resource services. 

4.2 Target Platform Model 

The target platform model (TPM) specifies all information necessary 
for complete and automated platform mapping and synthesis: 

■ the target architecture model (TAM) in which the resources and re- 
source services provided by the platform for application implemen- 
tation are modelled. Resources are hardware devices and execution 
environments, like reconfigurable devices, microprocessors, com- 
munication paths, storages, and run-time environments. The re- 
source services of each resource comprise an abstract operation set 
which defines the resource’s functionality. Each resource service is 
characterized by its implementations and their QoS-characteristic 
(quality-of-service), like latency, area, and power consumption. 
Services provided by resource types, like storages or communica- 
tion paths, are modelled similarly. Additionally, for each abstract 
operation implementation, implementation language specific rules 
and patterns, and necessary libraries are given. 

■ the model compiler components to be used for hardware resource 
specific platform mapping, estimation, generation, as well as the 
interpreter of the generated output, like synthesis or compilation 
tools, are modelled in the TPM. By means of these components the 
model compiler dynamically adapts its back-end to the hardware 
architecture. 

UML 2.0 enables us to describe the TPM entirely with UML and MAL. 

4.3 Hardware Platform Mapping 

Activities and Artifacts. Hardware platform mapping is the trans- 
formation of the PIM (or a partial PSM) of the system into a HSM. 
During hardware platform mapping we identify a partitioning of the 
system function among the components of the target hardware architec- 
ture. It is performed by iteratively changing the model structure and 
behavior such that it can be implemented on the given target platform. 
Model transformations are described with mapping operators. The de- 
sign space, as defined by the target platform, is explored for feasible 
implementations by the iterative application of the mapping operators 
to the model. 
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The structure and representation of the HSM is discussed in section 
1.4. 3.0. Hardware platform mapping algorithms and the mapping op- 
erators are briefly discussed in section 1.4. 3.0. For the purpose of this 
article we will focus on the language related aspects. 

Hardware Specific Model. The hardware specific model defines the 
partitioning of the system function among the resources of the target 
platform by means of establishing relations between the elements of the 
PIM and the according elements of the TPM being used to realize the 
PIM elements. The HSM depicted in Figure 1.2 comprises of the follow- 
ing models (due to space limitations not shown in the figure): 

■ an implementation model, which represents the mapping of design 
model subsystems and classes to implementation subsystems and 
classes and their mapping to components. For each implemented 
element of the PIM this model specifies which resource services are 
allocated for its implementation. 

■ a deployment model, which represents the mapping of the compo- 
nents of the implementation model to the components of the target 
architecture model. 

The implementation and deployment model are described in the UML 
and MAL. That is, the HSM can be executed, verified, and visualized 
using the same algorithms and tools as for the PIM. Moreover, this allows 
the developer for a (semi-) manual partitioning by providing complete 
or partial versions of these models. Partitions computed by the model 
compiler can be changed or visualized using ordinary UML modelling 
tools. 

Mapping Algorithms. We based partitioning on objects, mainly for 
two reasons. First, objects are a fundamental source of concurrency. 
Each object can be seen as an abstract machine providing services that 
may be requested by other objects by means of messages. All objects of 
a system execute concurrently; synchronization is reached through the 
messages. This object-based model of computation maps well to RTR- 
architectures comprising of multiple, possibly reconfigurable, processing 
elements. Second, objects encapsulate data and behavior to process 
the data. During partitioning of objects, both function and data are 
partitioned, which can reduce communication effort. 

To transform the PIM into a PSM we defined a set of mapping op- 
erators. We distinguish three classes of transformations: allocations, 
behavior transformations, and structure transformations. Allocation op- 
erators act on all realized model elements. They map model elements 
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to the target architecture by assigning sufficient sets of resource ser- 
vices. Behavior transformations operate on UML behavior definitions, 
like state machines and activities, and the model elements which im- 
plement them. Structure transformation operators operate on model 
elements from which the model structure is built. Table 1.1 describes 
the mapping operators. 



Table 1.1. Mapping Operators 



| Operator 


Description J 


Allocation Operators 


Allocate /Deallocate- 
(Resource Service Set, 
Element) 


Allocates or deallocates a set of resource services 
from the element. In case of Allocate the element 
is realized with the resource services in the set. 


Behavior Transformation Operators 


DECOMPOSE(Behavior) 


Splits the given behavior into a set of behaviors that 
collaboratively implement the same functionality as 
the original behavior. This operator must be used 
in conjunction with lMPLEMENT(Behavior, Opera- 
tion/Class), and JoiN(Operation, Class) in case of 
the former, in order for the resulting model to be 
valid. 


lMPLEMENT(Behavior, Op- 
eration) 


Associates the behavior to the operation. The be- 
havior defines the implementation of that operation. 
The operation provides the interface to the behav- 
ior. 


lMPLEMENT(Behavior, 

Class) 


Associates the behavior to the class. The behavior 
defines the states the instances of the class may be 
in during their life-time. 


Structure Transformation Operators 


JoiN/SPLiT(Feature, 

Class) 


Join (split) a feature, like attribute or operation, 
to (from) a class. In case of Join the class will 
encapsulate the feature. 


JoiN/SPLiT(Class, Compo- 
nent) 


Join (split) a class to (from) a component. In case 
of Join the component will realize the class. 


JoiN/SPLlT(Component, 

Device) 


Join (split) a component to (from) a device. In case 
of Join the component is deployed on the device. 



The type, operands, sequence, and the degree of automation of the op- 
erator application is subject to the concrete mapping algorithm. Given 
this framework one can think of many different mapping algorithms. The 
feasibility of an algorithm depends on its specific trade-off between the 
quality of the computed solution and the effort to compute this solution, 
which not only depends on the mapping algorithm itself but also on its 
input - a PIM or a partial solution of a PSM, and the TPM. 
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In general mapping algorithms comprise of three major steps: compu- 
tation and pre-estimation of candidate mappings, selection of mapping 
sets, and application of mapping sets. Candidate mappings are com- 
puted for each realized model element. They are described in terms of 
the presented mappings operators. The number and type of candidate 
mappings being computed for a specific model element is a function of 
the element’s expected utilization. For instance, for model elements the 
number of pre-computed allocation mapping candidates may be a func- 
tion of its execution probability and frequency [3]. Thereby we account 
for the different implementation options of each element. Moreover, 
this allows us to adjust the trade-off between compilation time and the 
quality of the computed model mapping. The local QoS of each can- 
didate mapping is preestimated using the QoS information modelled in 
the TPM. 

The actual mapping is performed by selecting and applying a set of 
candidate mappings to the PIM or a partial version of the PSM. We 
start by computing a complete PSM, which is then progressively re- 
fined such that the quality of the overall mapping is optimized. For 
this we iteratively select sufficient sub-sets of candidate mappings and 
estimate the effect of their application to the model. Then we decide if 
the mappings shall be applied, and if so, we apply them. The compiler 
validates that at each step the selected set of mappings is consistent 
and complete, in that none of the mappings affects another mapping 
and the resulting PSM describes a complete mapping. The strategy for 
the selection and application of mapping sets is subject to the concrete 
mapping algorithm. For instance a simulated annealing algorithm will 
typically select candidate mappings for only a small number of cohesive 
model elements and apply those mappings which improve the current 
solution. A branch-and-bound algorithm may apply the mappings in a 
deterministic order and apply only the best. 

We implemented the described framework in the MOCCA-compiler. 
Currently, MOCCA provides six mappers which employ different strate- 
gies for mapping selection and application, like randomized search or 
branch-and-bound. The mappers are parameterizable and may be com- 
bined with each other such that a PSM computed by one mapper is the 
initial solution for the next mapper. 

4.4 Software Platform Mapping 

Given a hardware specific system model, that is a model in which 
parts of the behavior are mapped to the suitable hardware components, 
we proceed by completing the platform specific model of our system. 
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The basic behavior of the system is specified with UML actions. In 
addition each non-trivial UML model contains behavior, which is and 
can not be described with actions alone. The realization of this behav- 
ior mostly requires services provided by the underlying run-time envi- 
ronment and synthesis libraries. It is important to note, that in the 
PIM we are not to specify such realizations, because this would violate 
platform independence. It is the task of the software platform mapping 
step to bind these behavior to the resources required for their actual 
realizations. Examples of such mappings are 

■ active classes are mapped to threads/processes of the underlying 
operating system. 

■ operation guards are mapped to mutexes/semaphores of the un- 
derlying operating system. 

■ state machines may require a storage and access mechanism for 
events. Further run-time support may be necessary depending on 
their actual realization (table driven, direct encoding, ... ) 

■ associations with multiplicities greater than one require a storage 
and access mechanism for the references to associated objects. 

The resources which comprise the software platform are described in 
the target platform description. For each respective model element the 
model compiler selects the required resource and binds it to the model 
element. The binding information is transparently included in the HSM 
by means of UML extensions mechanisms, so, if required, it may be 
changed by the developer. 

5. Synthesis 

Given a platform specific model of our system, we proceed by im- 
plementing it into an ready-to-run application. Figure 1.3 shows the 
activities and artifacts of this step. 

Central activity is the synthesis of the platform specific implementa- 
tion, comprising of hardware and software modules and communication 
interfaces according to the platform mapping. Synthesis is performed 
on the basis of the implementation and deployment models. For the 
elements realizing UML components we synthesize an according imple- 
mentation. The implementation language is specific to the processing 
element on which the component will be deployed. 

Synthesis depends on the used implementation language and language 
specific transformation patterns and rules. In our approach these are in- 
corporated in the language specific back-ends of the model compiler. We 
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4 

Platform Dependent Application 



Figure 1.3. Synthesis - Activities and Artifacts 



currently support C++ and Java for implementation of software com- 
ponents and VHDL and Java for the Xilinx Forge compiler for hardware 
components [14]. 

For detailed synthesis/compilation to configuration bit-streams/exe- 
cutables we use commercial tools. Synthesis and compilation are pa- 
rameterized with the design constraints in the model. After synthesis 
and compilation we integrate the bit-streams and executables into the 
application which can directly be executed on the target platform. 

6. Conclusions and Future Work 

In this article we presented an approach and a supporting environment 
for the object-oriented system-level development of applications for run- 
time reconfigurable computer systems. To overcome some of the draw- 
backs of approaches which use conventional programming languages for 
system specification, we use the universal syntactic and semantic frame- 
work provided by the Unified Modelling Language. To enable model 
execution, early verification and simulation, design space exploration, 
and automated and complete synthesis we extended the UML by an 
appropriate action language. 

We have shown that this approach enables a seamless and comprehen- 
sible transition of the system specification to a ready-to-run application, 
without the need to change the applied paradigms, methods, or language 
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in between. Also the presented approach defines a comprehensible de- 
velopment process, which incorporates the hardware-software co-design 
into the general approach of Model Driven Architecture. Although UML 
and MDA were not explicitly designed for the development of hardware- 
software systems, we beneficially utilize them. 

The development process and the MOCCA model compiler as pre- 
sented in this article are functional [11]. The flexible architecture of 
the model compiler makes it retargetable to different input specification 
languages and representations, target platforms, and development en- 
vironments. Future will include the development of platform mapping 
algorithms and accompanying heuristics specialized to object-oriented 
systems. 
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Abstract In this article we show how to use the Rialto intermediate language, to 
capture the semantics of UML behavioral diagrams. The Rialto lan- 
guage has a formal semantics given as structural operational rules and 
it supports semantic variations. It can be used to uniformly describe 
the behavior of a combination of several diagrams and as a bridge from 
UML models to animation and production code. 



1. Introduction 

The Unified Modeling Language (UML) [1] can be used to model the 
architecture and behavior of any kind of software project. This is due 
to the fact that UML provides many different diagrams or views of a 
system: class, component and deployment diagrams focus on different 
aspects of the structure of a system while the behavioral diagrams such 
as use case, statechart, activity and interaction diagrams focus on its 
dynamics. 

All the behavioral diagrams except use case diagrams are closely re- 
lated. We can convert a collaboration diagram into a sequence diagram 
and vice versa. Statecharts are used as the semantic foundation of the 
activity diagrams and it is possible to represent an execution (a trace) 
of a statechart or an activity diagram as a sequence or collaboration dia- 
gram. However, at the formal level, we consider that the UML standard 
lacks a consistent and unified description of the dynamics of a system 
specified using the previous diagrams. 
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Many authors are working towards a formal semantics for UML [2]. 
Formal semantics give an unambiguous interpretation of UML using a 
mathematical formalism; some of the recent works in this direction are 
the semantics for statecharts e.g. [3] and [4] and activity diagrams [5]. 
Although these articles are sound and inspiring, they do not study the 
semantics of multiple diagrams combined. 

In this paper, we show how we can formalize the behavior of UML 
diagrams, including the combined behavior of several diagrams, using 
Rialto. Rialto is an intermediate language that can be used to describe 
multiple models of computation. A model of computation is a domain 
specific, often intuitive, understanding of how the computations in that 
domain are done: it encompasses the designer’s notion of physical pro- 
cesses, or the “laws of physics” that govern component interactions. UML 
statecharts (a chapter in [1]) is an example of an asynchronous model of 
computation while languages like Esterel [6] or Harel’s Statecharts [7] 
have semantics based on the synchronicity hypothesis (a variant of the 
synchronous computational model). 

We have had as our starting point the observation that many language 
constructs are common to different languages, but their semantics differ 
due to the computational model. E.g. parallelism in UML has a very 
different semantics from parallelism in Esterel. In [8] , Lee touches the 
subject of decoupling an abstract syntax from the model of computa- 
tion, i.e. he suggests that a language, or a set of languages, with a given 
abstract syntax, can be used to model very different things depending 
on the semantics and the model of computation connected to the syn- 
tax. In the context of UML, this phenomenon can be observed e.g. with 
statecharts and activity diagrams. An activity diagram can be inter- 
preted as a statechart where all computation is done in state activities 
and the transitions are triggered by completion events. Therefore, we 
can say that activity diagrams have data flow as their underlying model 
of computation. In Rialto, we define different scheduling policies for dif- 
ferent computational models. The policies define atomic execution steps 
and hence we can for instance model synchronicity in a way similar to 
that of SystemC for instance. It is this interaction between language 
constructs and models of computation that is the focus of our research 
and our motivation for introducing Rialto as a language for describing 
the behavior of UML. 

We are also applying this new insight on the combined behavior of 
UML models to construct tools to animate the models and generate 
optimized code. Model animation enables a designer to validate a model 
before the design and implementation has been completed. Rialto can be 
used as an execution engine for UML models, and is hence also related 
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to the work on executable UML [9] . Rialto can also be used to generate 
code for different target languages, including C and VHDL. 

The translation from 
UML models to Rialto is 
automatically performed 
using the SMW toolkit [10] 
as shown in the figure. 

The SMW toolkit can be used to transform and extract information 
from UML models. SMW can read UML models created by any XMI- 
compliant UML editor. The generated Rialto code is compiled into tar- 
get language code by the Rialto compiler. The whole process can be 
made totally transparent and we have created prototype model compil- 
ers like uml2cpp and uml2vhdl that read in XMI files and output C++ 
and VHDL code. 

This article is divided into three parts: We start by introducing Ri- 
alto, our intermediate language, then we explain how we represent UML 
statecharts, activity diagrams and collaboration diagrams in this lan- 
guage. Finally, we describe our strategy for code generation from Rialto 
to target language code. 

2. The Rialto Intermediate Language 

Rialto is a textual language for multiple models of computation with 
formal semantics. It can be used as a stable platform for interfacing 
UML behavioral models with tools for code synthesis, animation, ver- 
ification etc. We do not expect the average UML practitioner to use 
Rialto. Instead, we intend it to be both a tool to study the generation 
of efficient code and a tool for UML scholars to discuss different aspects 
of UML behavioral semantics. The Rialto language is more abstract 
than usual programming languages since it supports concepts like traps 
(high-level transitions), suspension and resuming of threads, and event 
queues. The language has been specifically designed to describe the be- 
havior of modeling languages and it can be used to combine multiple 
heterogeneous models of computation [12]. 

In this section we shortly present some syntactic elements of Rialto, 
give a semantics for the statements in terms of structural operational 
rules and show how we can use different scheduling policies to give dif- 
ferent behavior to different parts of a system. 

2.1 Syntax 

Every statement in a Rialto program has a unique label, which can e.g. 
correspond to the name of some UML element, or it can just be a unique 
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name given by the precompiler of the language. The key abstraction 
in the language is the state block. It can represent different entities 
in different domains, it also represents a scope that can be assigned 
a scheduling policy, as described below. A state block is declared as 
follows: 

state 

# declarations, traps and scheduling policy 
begin 

# substates, sequential code 

end 

If we plan to use the same state block more than once, we can define 
a stateType to avoid code duplication. A stateType is declared as 
follows: 

typename: stateType ( ([in I out] port)* ) 

# state definition 

end 



Where the “state definition” is a normal state block and the ports are 
channels used by the stateType to communicate with other entities. A 
stateType is instantiated as: label: typename ( ql (, q2 )* ). 

We have included in the language some concepts that are common 
to different models of computation, but can have different semantics 
depending on different computational models. We will now give a short 
description of some of the concepts and show how they are represented 
in Rialto. 

State A state in a UML or Harel’s statechart can be represented di- 
rectly in Rialto by a state block. As in UML statecharts, Rialto states 
can contain substates, which can also be orthogonal. Interrupts and 
transitions An interrupt is an event of high priority. In our language, a 
trap statement is used to monitor interrupts. Interrupts correspond to 
trap in Esterel and transitions going upwards in the state hierarchy 
in both UML and Harel’s Statecharts. The goto statement is used to 
do transitions from a state to another. A trap that monitors an event 
e on a queue q and does a transition to a state A is declared as follows: 
trap q.e do goto (A). 

Concurrency Concurrency means that several statements are exe- 
cuted in parallel. In our language, concurrency is defined using the par 
statement, where the arguments are the labels of, usually state state- 
ments, which should be run in parallel. The scheduling policies manage 
concurrent threads, which reflects the computational model. 

Thread Synchronization Concurrent threads in a system often 
need to be synchronized, for instance two parallel activities in an ac- 
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[par] 

[goto] 

[trapi] 



l £ a C(l) = par( Zi, I 2 , • • • , Z n ) 

(a,£) >- 1>a - (a - WUr=ift},£> 

Z £ a £(Z) = goto(Zi, • • • , Z n ) 

goto (i 1 , • • • , in ) 

(a) * (a: — subtree (l, 1 1 , • • • , Z n ) U { Z 1 , • • • , Z n } U entry stats) 

l £ a 6 £(Z) = trap 6 do Si (a U {£ -1 [5i]}, £) -i (a ' , £ 7 ) 



7aWe 2.i. A subset of the operational rules of the language 



tivity graph are synchronized by a join pseudo-state. In Rialto we can 
specify a synchronization boundary by encapsulating threads within a 
state block, which activates its successor when each of the contained 
threads has finished. 

Communication policy A communication policy states how differ- 
ent modules of the system communicate with each other. The commu- 
nication mechanism we use with UML statecharts is a simple fifo queue. 
In state diagrams, an event is an occurrence that may trigger a state 
transition. In UML statecharts, there is an implicit global event queue. 

2.2 Operational Semantics 

To define the operational semantics of the language we need to for- 
malize the structure of a Rialto program. The labels of the statements 
act as values for program counters. The set of labels S is organized in 
a tree structure by the child relation | (The tuple (£, j) forms a label- 
tree). This reflects the scoping of the program. We can take the closure 
i* of j: let l\ and 1 2 be labels; then l\ j* I2 means l\ is a descendant of 
I2 or in other words: l\ is inside the scope of 1 2. The successor relation 
SxS orders the labels sequentially, If h, h € £ and l\ y I2 then I2 
succeeds l\ in the program. C : S — ► statement is a total function that 
maps each label to its statement. 

We can now identify a program by the tuple ( S, j, >-,£ ). The state 
configuration of a program is represented by a tuple a = (a, 7, £), where 
a C S is the set of active labels, 7 is the set of suspended labels and £ 
is the data-state. We have separated the control-state represented by a 
and 7 from the data-state £, which maps values to variables. The active 
set a represents the current values of the program counters. A subset 
of the operational rules that update the state configuration is given in 
Table 2 . 1 . The rules determine how the statements update the state of 
a system and we give a short explanation of the axioms next. 
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The par statement can act when its label is active; it adds all of its 
arguments to the active set. Note that the par statement just creates 
new threads. It is the job of the policy to decide how to schedule the 
threads. The goto statement is used to switch from an active state to 
another state. It can take many labels as parameters, which allows it 
to be used to model fork transitions. A goto is enabled when its label 
is active; it removes the subtree containing the source and target labels 
from the active set (given by the subtree helper function), and activates 
the target labels (belonging to state statements) along with any labels of 
trap statements or entry actions that are ancestors of the target labels 
(the entry stats helper function). The trap statement is defined by two 
rules representing the cases where the guard evaluates to true or false. 
The trapA rule shows the true branch, which adds the label of the do 
statement to the active set, executes it immediately (atomically), and 
leaves the system in the state reached by this execution. 

2.3 Scheduling Semantics 

The presented operational semantics leaves nondeterminism in the 
scheduler when several labels are active at once. This nondeterminism 
is resolved by the scheduling policies. An execution engine picks labels 
from the set of active labels a accoring to the policy in the scope, and 
then executes the rule corresponding to the statement of that label. 

A scheduling policy connected to a state block, schedules the sub- 
states according to a given algorithm. A program is executed by re- 
peatedly running the policy of the topmost state in the hierarchy. The 
topmost policy will then schedule the states down in the hierarchy, which 
can have different policies assigned to them. The entity that calls the 
scheduling policy of the top-level state can be thought of as a global clock 
in the system. To define a scheduling policy we need a helper function. 
A label that belongs to a simple statement is enabled iff the premiss of 
the rule that corresponds to the statement holds; if a label belongs to a 
state statement, it is enabled iff it is active or has descendants that are 
enabled. A label can also become blocked by the scheduler, and is then 
not enabled. The enabled(l, cr, (3) function returns the set of enabled labels 
that are descendants of l. We will use this function in the actual 
definition of the scheduling policies. A schedul- 
ing policy function accepts as parameters 
the current state of the program a and the 
blocked set (5 and returns the next state 
of the program. As an example, the algo- 
rithm on the right implements a step scheduling policy that executes 



run (a, (3) 

p ■— enabled(self,o, (3) 

for each k in p a do 

o' ■.= li.R.UN(o, 0 ) 

return o' 
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1 Philosopher: stateType(out left, out right) 

2 event eat, sleep; 

3 begin 

4 # behavior of Philosopher 

5 end 

6 

7 Fork: stateType( in phil ) 

8 event get, release; 

9 begin 

10 # behavior of Fork 

1 1 end 



Figure 2.1. A UML class diagram and Rialto code 



all enabled statements in the same step. Note that self refers to the 
state block whose RUN function was called. In the next section we will 
present other scheduling policies used to model different UML execution 
models. The scheduling policies have also been formalized as another 
level of operational rules working above the rules for the statements, 
but this work is not presented in this text. 

3. Representing UML models in Rialto 

In this section we describe how we translate a UML model into Ri- 
alto code. This transformation has to deal with the fact that UML is a 
family of languages, both at the semantic and the syntactic level. It is 
possible to create different translators for different semantic interpreta- 
tions of UML. We currently support statecharts, activity diagrams and 
collaboration diagrams. 

We show as an example the translation of a collaboration of objects 
whose behavior is modeled using statecharts or activity diagrams. Fig- 
ure 2.1 shows a UML class diagram with two classes Philosopher and 
Fork along with the Rialto translation consisting of two corresponding 
stateTypes. There are two associations connecting the two classes, in- 
dicating that a Philosopher has a left and a right fork. This is reflected 
in the Rialto code by the two outgoing ports of the Philosopher type 
and the incoming one in the Fork type (we only use one incoming event 
queue for all connections). The behaviors of the two classes would be 
modeled using statecharts and the Rialto translations of the statecharts 
would appear inside the stateTypes. 

3.1 Statecharts 

A state in a statechart is represented by a state block; hierarchi- 
cal compound states are naturally written as nested state blocks. The 
first state block in a compound state is the initial state. Transi- 
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tions can be represented using the trap statements for monitoring an 
event or value of a guard, and the goto statement to take the transition. 
Also orthogonal regions are represented by state blocks, with a par 
statement specifying that the states (regions) are to be run orthogonally. 
Fork pseudostates are simply achieved by providing the goto statement 
with several state labels as parameters (goto (a, b) does a transition to 
the two states a and b, which are run orthogonally). History pseu- 
dostates are represented by suspend statements, that store the state of 
a block until it is re-entered. 

The semantics of UML statecharts is based on a run-to-completion 
(RTC) step. The RTC algorithm fires transitions in the statechart based 
on the event on the queue, and dispatches it at the end of the RTC step. 
In addition to the translations described above, we need to provide a 
scheduling policy that runs the code according to the RTC algorithm. A 
state executing the RTC policy runs until no more runnable labels exists 
in its scope. The algorithm is shown below. It first runs all the enabled 
statements, and then checks if there appeared any new enabled labels, 
adding any labels that are not ancestors of the original enabled labels 
to the blocked set (line 5). If there are enabled non-blocked labels, it 
runs again. By this blocking, we ensure that when a state transition is 
taken during a RTC step, the newly activated state will not be executed 
during that same step. 

run(a, /?) 

p := enabled(sel f, a, 0) 
for each k inp do 
o := li.RUN(a, 0) 
p' ■— enabled(a ' , self , p) 

ff := {lj G p' | C[lj\ = state A lj $ { ran(p < 1* ))} 
if p' ~ P' f 0 then 

return self.RUN(a',/3') 
dequeue; 

return a 



The <1 symbol is the domain restriction operator from the Z notation. In 
Figure 2.2 a) we show a simple statechart with a composite state divided 
into two orthogonal regions. The corresponding Rialto code is shown in 
Figure 2.2 b). This code has been generated by a tool as described 
in Section 2.4. The scheduling policy for the top-level state block in 
the code is set to RTC in line 2, and the queue ql, and the events are 
declared in line 3. The S state listens to event e2 on queue ql and fires 
the transition to state d if it is present (line 5). The par statement in 
line 7 activates the regions SI and S2 orthogonally. 
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top: state 
policy rtc; 

queue ql; event el, e2; 

S: state 

trap ql.e2 do goto(d) 
begin 

par ( SI, S2 ) 

SI: state 
a: state 

trap ql.el do goto(b) 
end 

b: state end 
end 

S2: state 
c: state end 
end 
end 

d: state end 
end 



Figure 2.2. a) An example UML statechart b) the corresponding Rialto code gener- 
ated by the tool 



3.2 Activity Diagrams 

The translation of activity diagrams follows a similar schema. The 
activity states are represented by state blocks, forks are dealt with 
as in the statecharts; however, join pseudostates usually need to be ex- 
plicitly modeled using a state block for synchronizing the threads. The 
scheduling policy for an activity graph depends on the desired behavior, 
which is not specified in the UML standard. If we apply the RTC policy, 
the model will run in steps of one activity, i.e. at each invocation the 
active states will run to completion and the step will finish. Another 
possibility could be to specify a policy that runs the complete algorithm 
modeled by the activity graph at each invocation. Here we use the sim- 
ple step policy introduced previously, which for each invocation runs all 
the enabled labels and returns (runs one statement in each thread). 

As an example, we show a simple activity diagram and its translation 
into Rialto in Figure 2.3. After the activity in a is completed, we take 
a forked transition to b and c (line 6). This transition (goto(b,c)) 
activates both b and c that is they will run concurrently without using 
the par statement. The join state encapsulates the threads b and c and 
works as a synchronization boundary. It is sequentially composed with 
the d state, which it activates when all its children have finished. 

3.3 Collaboration Diagrams 

Statecharts and activity diagrams model the behavior of objects, while 
collaborations show an interaction between objects. We can use Rialto to 
capture the behavior of systems modeled using collaboration diagrams, 
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1 activity: state 

2 policy step; 

3 begin 

4 a: state begin 

5 # code block for a 

6 goto(b, c) 

7 end 

8 join: state 

9 b: state begin 

10 # code block for b 

11 end 

12 c: state begin 

13 # code block for c 

14 end 

15 end; 

16 d: state # code block for d end 

17 end 



Figure 2.3. A simple Activity Diagram 



where the objects can have behavior described by either statecharts or 
activity diagrams. The objects are represented by state blocks (or 
instantiations of stateTypes), which are defined to run concurrently 
using the par statement. The objects can communicate through queues. 
The default scheduling policy for a collaboration diagram is interleaving. 
This means that each object in the collaboration runs in its own task 
and is scheduled nondeterministically. The interleaving policy picks a 
label from the enabled set nondeterministically under the fairness 
assumption (The :€. in line 2 in the al- run (a. (3) 

gorithm on the right denotes nondeter- p ■.= enabled (l, a, (3 ) 

ministic assignment). Alternatively, the h P 

step policy can be used, which allows retumk.RUN(a , 0) 

for active objects to execute at the same 

time during one step. When moving to code synthesis, we could have dif- 
ferent physical mappings of the scheduling policies. For instance choos- 
ing a interleaving_C_posix policy would map the threads scheduled 
by the interleaving policy into posix threads instead of using the Rialto 
scheduler. 

The behavior of an object can be described using a statechart or an 
activity diagram. The internal behavior of that object will then be RTC 
or step. As an example, we can model a collaboration of two philoso- 
phers and two forks as in Figure 2.4. The ports are connected to event 
queues when the types are instantiated. The associations from the class 
diagram are also instantiated as links connecting the objects. In the cor- 
responding Rialto code, we show how the stateTypes are instantiated. 
The par statement activates all the objects in parallel. Two queues are 
declared in the top-level state block dinner. They are connected to 
the ports of the objects. This actually means that queue ql is the event 
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1 dinner: state 

2 policy interleaving; queue ql , q2; 

3 begin 

4 par (john, paul , forkl ,fork2) 

5 john: Philosopher (q2,ql) ; 

6 paul: Philosopher (ql ,q2) ; 

7 forkl: Fork(ql) ; 

8 fork2: Fork(q2) ; 

9 end 



Figure 2.4. Objects and links instantiated 

queue of the statechart of forkl while q2 is the queue of the fork2 
object. The Rialto program is run by repeatedly calling the top-level 
scheduling policy. In this case it is the interleaving policy of the din- 
ner state. That policy will pick one of the parallel blocks and call its 
scheduling policy, which in this model will be a rtc policy. 

3.4 Automatic UML to Rialto Translation 

The translation from UML models to Rialto is performed with the 
help of the SMW toolkit [10]. This toolkit is based on the Python 
programming language and it can be used to transform and extract 
information from UML models. It can read XMI [13] files created by any 
XMI-compliant UML editor. Once a model is loaded, we can navigate 
it using queries like in OCL and transform it using Python imperative 
statements. 

In the code below, we use several functions for text manipulation: The 
vertical bars add a string to the final Rialto code. E.g. the statement 
I 2+2= | 2+2 will add the string "2+2=4" to the output code. The inden- 
tation of the code is controlled using | -» | and I <<- I . The * operator 
on a text list generates a string with the concatenation of a list using the 
second operand as a separator. For example ["a" , "b" , "c"] * " or " 
returns a or b or c. 

The following function converts a UML state to Rialto. We assume 
that the reader is familiar with the OCL language and the UML rneta- 
rnodel for statecharts. The function accepts as parameters an object 
representing a state in a statechart and the name of the input queue to 
be used. We use the trap statement to model the high-level transitions 
that exit the state. The function is called recursively in the case of com- 
posite states that contain other states. In concurrent composite states, 
the subvertices are orthogonal regions that run in parallel using the par 
statement. 




paul: Philosopher 



def StateVertex2Rialto (s, queue) : 
s .name I : state I 
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l-»l 

for t in s. outgoing: 

Itrap I queue |.| t .trigger .getDescriptionO | do | Transition2Rialto(t) 

l«-| 

if s . oclIsKindOf (CompositeState) : 
if s. subvert ex. size()>0: 

I begin I I -» I 

if s . isConcurrent : 

I par (I s. subvert ex. name * |)| 

for subState in sortByInitialState(s . subvertex) : 

StateVertex2Rialto (subState , queue) 

I «- I I end I 

We omit the implementation of the helper functions due to space 
constraints. The full script is available from the authors. 

4. Animation and Code generation 

One of the objectives of the Rialto language is to facilitate the an- 
imation, code generation and verification of UML models containing 
complex behavior. Using Rialto and our code generation approach, we 
can model the system using object-oriented techniques and the UML, 
while being able to generate efficient code in target languages that may 
not be object-oriented. This makes our method useful for designing em- 
bedded systems that can run on simple processors with limited memory 
and limited support for high-level programming languages. We can also 
generate hardware descriptions in VHDL for instance. 

We currently have two strategies for generating code from Rialto. The 
simplest one, which we have implemented in C++, is an execution en- 
gine approach. The code generated using this approach is not optimized, 
but reflects the structure of the Rialto model, i.e. the generated code 
has one object for each Rialto statement. Therefore, this approach is 
suitable for animation. We will not explain this approach any further in 
this text due to the space limitations. The second strategy for code gen- 
eration involves translating the model into finite state machines which 
are reduced using S-GRAPHs. 

The optimized code generation process translates the Rialto program 
into a FSM representation, which can be reduced in a way similar to that 
of the POLIS approach [14]. This method is based on Software Graphs 
or S-GRAPHs and it is described in more detail in [11] and [15]. An S- 
GRAPH is a directed acyclic graph used to describe a decision tree with 
assignments, which can be reduced. From the obtained optimized low- 
level representation, we can easily generate target language code in e.g. 
C or VHDL. Compact assembly code could also be synthesized directly 
for targets lacking higher level language compilers. 

The translation of a Rialto model into optimized code proceeds in five 
steps: Translation (flattening) of the Rialto code to a simple finite state 
machine, translation of the FSM into an S-GRAPH, optimization of the 
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S-GRAPH, translation of the S-GRAPH into a target language and, finally, 
compilation into machine code or synthesis of a hardware netlist. 

We have achieved up to 30 percent code footprint reduction when 
generating C code and compiling it into object code. We expect also 
good results in area reduction when synthesizing hardware from VHDL 
code generated from Rialto. The Rialto compiler still needs development 
and more real-life examples need to be tried to get a better picture of 
the benefits. 

5. Conclusions 

We have shown how we can use Rialto to describe the combined be- 
havior of different UML diagrams. Rialto can be converted into program 
code with the purpose of model animation or as a final production code 
to implement embedded systems with limited computational resources. 

The UML behavior diagrams include many concepts such as actions, 
events, states, etc. that are not present in most popular programming 
languages, like C+- (- or Java. This means there is not a one-to-one 
mapping between a behavioral diagram and its implementation. Some 
model elements, like history states, can be implemented in many different 
ways; this clearly contrasts with class diagrams, that often can be easily 
implemented in a programming language supporting concepts like classes 
and objects, composition and inheritance. Rialto can be used as an 
intermediate language between models and code and supports semantic 
variations thanks to our two-phase approach for code generation. 

An important decision in a code generation method is whether the 
programmer will be allowed to edit the produced code or not. We have 
opted to hide the final implementation from the programmer. This im- 
plies that the code does not need to be intelligible by a human program- 
mer, and that it is not necessary to reverse engineer the code back into a 
UML model. However, this approach requires, in order to be practical, 
that the produced code is so efficient that the programmer does not need 
to tweak it by hand. 

Acknowledgements: Dag Bjorklund gratefully acknowledges financial 
support for this work from the Nokia foundation. 
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Abstract With the increasing complexity of the emerging embedded real-time sys- 
tems, traditional design approaches can not provide sufficient support 
for the development of these systems anymore. They especially lack the 
ability to trace and analyse real-time system properties. In this paper, 
we investigate the design difficulties for embedded real-time systems and 
propose several principles for coping with these difficulties, which should 
be incorporated by an “adequate” design approach. Several prevailing 
design approaches are evaluated against these principles and their mer- 
its and drawbacks are examined and illustrated by examples. Finally, a 
platform-independent approach (POOSL[8, 9] + Rotalumis[20]) is intro- 
duced to remedy these design problems for embedded real-time systems. 
Initial experiments have been performed that confirm the advantages of 
this approach. 
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1. Introduction 

Over the past decades, we have witnessed a significant increase of the 
application of embedded real-time (RT) systems. These applications 
range from microchip product lines with microsecond response time to 
electric appliance controllers with seconds or minutes response time. The 
common feature of these systems is that the correctness of the system 
depends not only on the value of the computation but also on the time 
when the results are produced [18]. To guarantee timeliness feature in 
the system implementation, we expect the system behaviour to be pre- 
dictable and we would like to ensure in advance that all critical timing 
constraints are met. However, with the increase of complexity, tradi- 
tional design approaches are not well-suited for developing time-critical 
applications. We list below several typical characteristics in traditional 
design approaches that lead to unpredictable behaviour of embedded RT 
systems. 

Craft-based system implementation. Traditional methods are often 
bottom-up and driven by the specifics of the implementation platform. 
Critical timing constraints are dealt with in ad-hoc heuristic fashions. 
During system development, developers make implementation choices 
based on rough estimations of computation times. However, these com- 
putation times are in fact influenced by many non-deterministic factors 
of the underlying platform 1 . This severely hampers to make adequate 
estimations of computation times. Hence inadequate estimations can 
easily result in faulty design and implementation decisions. 

Ineffective design languages. Traditional programming or modelling 
languages usually do not provide sufficient support for embedded RT 
systems. 

1 These developing languages usually have platform-dependent exe- 
cution semantics, which means that the behaviour of the system 
is heavily affected by the (non-deterministic characteristics of the) 
underlying platform. This makes it very difficult to establish de- 
sign correctness. 

2 Design languages often have inadequate support for modularisa- 
tion. Modularity means that the system can be decomposed into 
independent subsystems and the composition of these subsystems 
have little impact on their own properties and functionalities[15]. 
Object-orientation helps developers improve the modularity of the 
software by grouping together data-structures and operations and 
encapsulating them from the outside world. In this way, a com- 
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plex system can be divided into independent subsystems that can 
more easily be designed , analysed and composed. However, in 
embedded RT systems, module independency is ruined by the fact 
that all modules running on one processor share the time resource. 
Therefore, after the composition of subsystems, the original real- 
time properties of the individual subsystems can not be sustained. 

3 Last but not the least, design languages often have little or no 
support for expressing timing requirements (such as deadlines and 
periods). This means that timing requirements cannot be taken 
into account when the system is mapped onto the target platform. 

Due to the above pitfalls, embedded real-time systems lack portability, 
adaptability, maintainability and reusability. Furthermore, the correct- 
ness and performance has to be established by extensive testing on the 
target platform. The disadvantages are obvious: 

■ Tests are usually carried out at the observable boundary of the 
system. It is hard to locate the specific internal details that cause 
(timeliness) errors. 

■ Additional test code may change the (real-time) behaviour of the 
system and may cause new errors (Heisenberg principe in testing 
[24, 16]). 

■ Test can only be carried out at a late stage in the design cycle. 
Failures detected at this stage often lead to expensive and time- 
consuming design iterations. 

■ Test results are affected by many uncontrollable external (envi- 
ronmental) and internal (non-deterministic factors). Some “rare” 
errors are hard to capture or repeat by test. 

2. The Dream: Platform-Independent Design 

The key problem of traditional approaches mentioned in the previ- 
ous section is that low-level details have a big influence on the system 
behaviour as a whole. Traditional design approaches do not provide 
facilities to abstract from these details adequately. In this sense, embed- 
ded RT system design suffers from “butterfly-effects”: a cache missing 
might result in a missed deadline. To cope with this problem, design 
approaches should offer adequate abstraction facilities and shield the de- 
sign from the details of the platform. Platform-independent approaches 
[12, 17] have been proposed to address this problem, which ideally have 
the following characteristics: 
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A well-founded 2 and expressive modelling language. The core of such 
a design approach is a modelling language which can help designers ex- 
press and verify their design ideas in an adequate way. This means that 
the language should be expressive, should have platform-independent 
semantics, operational semantics and adequate support for modulariza- 
tion: 

1 Adequate expressive power: Embedded RT systems often have fea- 
tures of timeliness, concurrency, distribution and complex func- 
tionality. To be able to expresses these features in a model, a 
modelling language should have facilities to describe system struc- 
ture, concurrency, communication, data types, non-determinism 
and timing. 

2 Platform-independent semantics: The non-deterministic factors in- 
troduced by the underlying platform make the simulation and ver- 
ification results of the design model unreliable and unpredictable. 
Platform-independent semantics of the modelling language gives 
a unique interpretation of the model and makes simulation and 
verification platform independent. Furthermore, it provides the 
flexibility to reuse the design model and target it to different or 
modified platforms. 

3 Operational semantics: Operational semantics of the modelling 
language lends itself naturally to executability. Inconsistency be- 
tween different aspects can then be located and correctness and 
performance properties can be checked either exhaustively (e.g. 
model-checking) or non-exhaustively (e.g. simulation). As a re- 
sult, many design errors can be corrected in an early development 
stage, avoiding costly and time-consuming iterations. 

4 Modularity support: Modularity is generally considered as the only 
available way for managing complexity of a system. Since com- 
plexity is a common feature of current embedded RT systems, it is 
necessary to embody modularity in the modelling language. This 
means that a concept of modules should be supported in such a way 
that module composition does not cause the real-time properties 
of the individual components to change. This allows components 
to be composed on basis of their interfaces, without have to un- 
derstand the internal details. 

Automatic and correctness-preserving transformation. System gen- 
eration should take a design model as blueprint and build a complete 
hardware/software implementation. Preferable, the generation of the 
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Figure 3.1. Comparison of several design approaches - The semantics of SDL is based 
on SDL-96 in CSDL[1]. ** TAU2 integrates concepts of SDL-2000 and UML 2.0 in 
its modelling language[3]. 



implementation should be largely automated. Furthermore, the trans- 
formation should also guarantee that the implementation behaves the 
same as the model. In this way, many errors caused by human-factors 
can be avoided during the system generation and correctness of the sys- 
tem can be guaranteed during the transformation. 

The above characteristics of design approach can help designers over- 
come the existing drawbacks of traditional design approaches and serve 
as guidelines for new embedded RT system design approaches. In the se- 
quel, we will discuss several prevailing design approaches for RT systems 
and evaluate them based on the above characteristics. 

3. Comparison of several design approaches for 
embedded RT systems 

Figure 3.1 gives a brief comparison of several typical design approa- 
ches 3 , all of which provide a powerful design language and most of which 
also support automatic software/hardware generation. In this way, soft- 
ware/hardware productivity can be improved and costly design interpre- 
tation errors can be reduced. However, none of them satisfies all those 
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characteristics of platform-independent design. In the following, we will 
investigate how those characteristics are supported by these approaches. 

3.1 Expressive power 

Timing. CSDL and TAU2 only support time delays. There is no ex- 
plicit timing expression in Esterel. Instead, it captures the time passing 
by counting activations of the system [5] . The modelling of physical time 
can be accomplished by counting activations issued at a regular time in- 
terval. Due to the deterministic characteristic of Esterel models (see be- 
low in this section) , this form of real-time mechanism is adequate enough 
for describing and analysing timing constraints. Compared to the other 
three approaches, ROOM [2] provides various timing services to express 
different timing constraints, such as delay timers, periodic timers, in- 
forrnln timers. However, its platform-dependent semantics does not give 
an unambiguous interpretation of time expressions in the model, which 
inhibits designers from analysing and predicting timing behaviour of the 
model. 

Structure, data type, concurrency and communication. These features 
are supported by all of these approaches. In this paper we are not going 
into detail about how these approaches support these features. For more 
information, we refer to [23, 19]. 

Non-determinism. Non-determinism is an essential way to manage 
the system complexity. It not only leaves freedom to obtain optimal 
implementations but also largely reduces the complexity of the model 
by abstracting it from irrelevant implementation details. Except for 
Esterel, all the three approaches can describe an embedded RT system 
at a high level of abstraction by using non-determinism. At the same 
time, they offer the possibility to model interested details of the system. 
Esterel sacrifices non-determinism to obtain a deterministic model of the 
system, in which the system behaviour is predictable. The cost of the 
deterministic characteristics is that complex behaviour is difficult to be 
modelled and analysed efficiently. 

3.2 Platform-independent semantics 

CSDL relies on an asynchronous timer mechanism which is able to 
access a global clock referring to the physical clock 4 . In this time mech- 
anism, the delay between the moment of timer expiration and the mo- 
ment at which the model reacts to this expiry is unbounded [23]. The 
unbounded delay is caused by several factors, such as the waiting time of 
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timer-expired message before it is inserted into the input message queue 
of the process, the time for consuming all messages before the timer mes- 
sage and the interaction time between the process and its input message 
queue [13]. When a timer is set to t seconds, the interpretation of this 
timer is in fact an arbitrary time duration dt ( dt G [t, oo)). Such a 
weak interpretation of timers cannot provide enough expressive power 
to describe the timing behaviour of real-time systems. The unbounded 
uncertainty of dt contradicts with the predictability of real-time system 
behaviour. 

Example 3.1 Consider a simple digital clock, which issues an action at 
the end of each second to count the time passing. Due to the unbounded 
uncertainty of a timer in CSDL, it is impossible to ensure that actions 
can be issued at (or close to) the expected time points. 

The time mechanism in CSDL is heavily affected by the platform-depen- 
dent physical clock. Such a platform-dependent timing mechanism can- 
not provide facilities to debug and analyse timing behaviour of a model, 
because any debugging and analysis observation may introduce extra 
time passing which changes the real-time behaviour of a model and leads 
to unreliable debugging and analysis results. The same problem holds 
for the ROOM approach. 

Different from CSDL and ROOM, TAU2 adopts a two-step execution 
model[14], the state of a system can change either by asynchronously ex- 
ecuting some atomic actions such as communication and data computa- 
tion without time passing (phase 1) or by letting time pass synchronously 
without any action being performed (phase 2). The semantics of Esterel 
is based on the perfect synchrony hypothesis [5], which assumes that a 
system’s reaction to an input is instantaneous. The time measurement 
is achieved by counting the number of events. The computation models 
of both TAU2 and Esterel adopt a virtual time, which is physical-time 
independent. In this way, real-time behaviour of their models is always 
predictable with respect to this virtual time. Therefore, the above un- 
bounded uncertainty problem does not exist in these design approaches. 
Furthermore, in these approaches, a model can be uniquely interpreted 
and analysed by verification and simulation techniques. Based on the 
analysis results, the model can be refined to meet predefined timing 
requirements. A clock example in section 4.1 illustrates that timing 
behaviour can be adequately modelled by such design approaches. 

3.3 Modularity support 

All of these approaches have object-oriented characteristic supporting 
data and functionality encapsulation. Due to the platform-dependent 
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semantics of CSDL and ROOM, timing characteristics of every module 
in the model are disturbed by the time consumption of other modules in 
the model and by other processes running on the same platform. On the 
contrary, both Esterel and TAU2 assume the underlying platform to be 
infinitely fast and the timing behaviour of the system is not constrained 
by the computation power of the underlying platform. Therefore, the 
composition of separate modules does not change their timeliness. As a 
consequence, the analysis of the design is easier and predictable. 

3.4 Correctness-preserving transformation 

As shown in Figure 3.1b, all approaches facilitate automatic software 
or hardware generation except for CSDL. In ROOM, automatic code gen- 
eration is accomplished by linking a model to a so-called service library 
which act as a virtual machine on top of different target platforms. In 
this sense, the implementation is in fact an executable model and prob- 
lems encountered in the model, such as platform-dependent semantics, 
are automatically inherited in the implementation. Although TAU2 can 
provide a reliable way to analyse a model and refine it to ensure the 
property correctness, it does not have a transformation mechanism to 
guarantee that correctness properties verified in the model can be trans- 
ferred to the implementation. In the automatically generated implemen- 
tation, timing expressions are simply interpreted as unbounded physical 
time, which faces the same unbounded uncertainty problem as in the 
CSDL model. The issuing time of actions can deviate much from those 
observed in the model. Furthermore, the ordering of events can also be 
different from those observed in the model. Here are several examples. 

Example 3.2 Accumulated timing errors: 

Consider a digital clock whose functionality is similar to that described 
in Example 1. The difference is that its accuracy is one tenth second 
instead of 1 second. Figure 3.2 shows that the timing errors 5 is accumu- 
lated during the execution of the implementation, which is automatically 
generated from the clock model in TA U2. 

EXAMPLE 3.3 Incorrect functionality caused by accumulated tim- 
ing errors: 

Consider a controller for a flash board showing 4 consecutive letters 
‘IEEE'’, whose functionality is described as follows. The four letters 
of the word are sequentially displayed on the board, and then wiped off 
altogether at the same time. The iteration will continue unless being 
interrupted manually. One solution to designing this controller is to 
use three parallel processes. Process I emits letter I every 0.3 seconds, 
process E emits letter E every 0.1 seconds and process space issues four 
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Figure 3.2. Accumulated timing errors of a TAU2 clock implementation 




Figure 3.3. Output of the controller 






Figure 3.4. Two parallel processes and the output of their TAU2 implementation 
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blank spaces every 0.3 seconds to erase the letters. The three processes 
starts from 0.01,0.02 and 0.25 second respectively. It is easy to verify 
that the model behaves correctly according the functionality specification 
in the tool of TAU2. However, we will see a different picture when we 
look at the behaviour of the implementation (working with the physical 
time). Figure 3.3 gives a snapshot of the output of the implementation. 
We can see that after several iterations, the accumulated timing errors 
has led to an incorrect output sequence. 

EXAMPLE 3.4 Incorrect functionality caused by duration actions: 

Not only can accumulated timing errors lead to incorrect event order, 
computation expense of individual actions can also result in unexpected 
behaviour. Consider the simple example of Figure 3. fa. Two parallel 
processes P and Q synchronize with each other at the beginning of each 
iteration to avoid the accumulation of timing errors. P sets a timer with 
3 seconds delay and Q sets a timer with 2.99 seconds delay. After the 
timer of Q expires, Q sends a ‘‘reply- signal” message to P. At the P 
side, there are two possibilities: 

1 P receives the timer expiration message and outputs the message 
“wrong”. 

2 P receives the reply message from Q, resets its own timer and 
outputs the message “correct”. 

It is not difficult to verify that the output message of the P should always 
be “ correct ” in the model. However, the automatically generated software 
implementation shows an unexpected behaviour (see Figure 3. 4b). 

Different from TAU2, Esterel provides a correctness-preserving trans- 
formation from a model to an implementation. The Esterel language is 
a synchronous concurrent programming language based on perfect syn- 
chrony hypothesis, which assumes computation actions take zero time. 
A pure Esterel model can be implemented in a digital circuit or software 
by using a formal transformation. Such a transformation keeps the se- 
mantics of the Esterel model to the hardware/software implementation 
except that perfect synchrony hypothesis is replaced by digital synchrony 
hypothesis (i.e. zero time is replaced by one cycle clock). The correctness 
of the generated implementation relies on the fact that perfect synchrony 
does not deviate very much from digital circuit synchrony [5]. 

4. Towards Platform-independent Design 

In the previous section, we have reviewed several typical design ap- 
proaches for embedded RT systems and analysed the drawbacks and 
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merits of each approach. Among them, TAU2 provides a relatively good 
support for modelling complex embedded RT systems but it provides 
no facilities for correctness-preserving transformation from a model to 
its implementation. Esterel has full support for correctness-preserving 
transformation for automatic hardware /software generation but its mod- 
elling language lacks ability to model complex interactive RT software 
systems [6]. In this section we propose an approach which considers all 
aspects introduced in section 2 and aims at platform-independent de- 
sign. It provides an expressive and well-founded language (POOSL) for 
modelling complex embedded RT systems and a correctness-preserving 
transformation tool (Rotalumis) for automatic software generation. Its 
ability to preserve correctness during transformation have been proven 
in [10]. 

4.1 POOSL 

In this section we give a brief overview of the POOSL language (Par- 
allel Object-Oriented Specification Language), which is employed in the 
SHEsirn tool and developed at the Eindhoven University of Technol- 
ogy. The POOSL language is equipped with a complete mathematical 
semantics and can formally describe concurrency, distribution, commu- 
nication, real-time and complex functionality features of a system in a 
single model. 

Similar to TAU2, the semantics of the POOSL language is based on a 
two-phase execution model which guarantees a unique interpretation of 
the model. Hence, behaviour of the model is not affected by underlying 
platforms. The detailed mathematical framework behind the POOSL 
language is given in [8, 20], and a formal description of its execution 
engine can be found in [9]. Figure 3.5 shows a simple clock in POOSL 
which performs the same functionality as in Example 1. Each event is 
accurately issued at the expected (virtual) time in this model (note that 
the ith event is issued at the ith second.). 

Because of the expressiveness and well-founded semantics of the POOSL 
language, it has been successfully applied to model and analyse many 
industrial systems such as a network processor[19] an microchip manu- 
facture device[ll] and a multimedia application [22], 

4.2 Rotalumis 

In this section, we outlines the formal transformation mechanism 
of software generation tool Rotalumis, which can transform a POOSL 
model into a software implementation for single processor platforms [21]. 
Different from other software generation tools, the Rotalumis supports 




